Real-time driver monitoring and feedback reporting system

ABSTRACT

Real-time feedback may be generated during a driving session from status data collected via one or more sensors. This feedback data may include various metrics related to a student&#39;s driving skills, which may be utilized to generate tagged driving events. A user may also manually enter tagged driving events. The tagged driving events may include real-time information based on the collected status data, such as acceleration, braking, cornering data, descriptions entered by the user. The location of these tagged driving events may be mapped in real time. Sensors used to collect this data may be integrated within the device displaying the feedback or located on another device, in which case the status data may be communicated to the device displaying the feedback. The displayed real-time feedback may be viewed by an instructor to assess a student&#39;s driving skills in real time and to calculate a driver feedback score.

FIELD OF THE DISCLOSURE

The present disclosure relates to systems, methods, apparatus, andnon-transitory computer readable media for use during driving tests,and, more particularly, to using one or more devices to providereal-time driver monitoring and feedback reporting to an instructorregarding a driving test session.

BACKGROUND

Traditionally, a student driver wanting to obtain a drivers' license maytake driving classes and/or participate in various driving sessionswhereby the student is evaluated on his driving performance. During atypical driving session, a student driver may be requested to drivealong a certain route while the student's driving skills are observedand evaluated by an instructor. Based on the instructor's observations,the student driver is graded according to a set of criteria.

BRIEF DESCRIPTION OF THE DRAWINGS

The figures described below depict various aspects of the system andmethods disclosed herein. It should be understood that each figuredepicts an aspect of a particular aspect of the disclosed system andmethods, and that each of the figures is intended to accord with apossible aspect thereof. Further, wherever possible, the followingdescription refers to the reference numerals included in the followingfigures, in which features depicted in multiple figures are designatedwith consistent reference numerals.

FIG. 1 illustrates a block diagram of an exemplary driver's educationevaluation system 100 in accordance with an exemplary aspect of thepresent disclosure;

FIG. 2 illustrates a detailed block diagram of a portion of exemplarydriver's education evaluation system 100 in accordance with an exemplaryaspect of the present disclosure;

FIG. 3 illustrates an example screenshot 300 of a device used to displaycurrent driving feedback data during a driving session in accordancewith an exemplary aspect of the present disclosure;

FIG. 4A illustrates an example screenshot 400 of a device used todisplay a driving session report after a driving session has beencompleted in accordance with an exemplary aspect of the presentdisclosure;

FIG. 4B illustrates an example screenshot 450 of a device used todisplay a driving session report after a driving session has beencompleted in accordance with an exemplary aspect of the presentdisclosure; and

FIG. 5 illustrates an example feedback display method 500 in accordancewith an exemplary aspect of the present disclosure.

DETAILED DESCRIPTION

To improve the efficiency and objectivity of the driver testing process,driver monitoring systems may incorporate other sources of datacollection in addition to the driver's observations. Using various datacollection techniques, one or more computers and/or sensors in thevehicle may record data throughout a driving session. The instructor maythen use a report generated from this data to provide feedback to thestudent and/or to evaluate the student's driving skills once the drivingsession has ended.

In spite of feedback provided in the generated report, the instructor'srole in determining the student's driving skills is important becausethe instructor may provide valuable feedback to the student during thedriving session. In this way, the student may be able to correctproblematic driving habits before the driving session has ended andbefore seeing the driving session report.

Although an instructor may provide the student with feedback during thedriving session, this feedback is typically limited to the instructor'sphysical observations of the student's driving skills, as the instructordoes not have access to the collected data until the driving session hasended and the report is generated. Therefore, providing instructors witha way to utilize the collected data in real time to provide studentswith feedback during a driving session presents several challenges.

I. Collecting Status Data and Displaying Status Metrics During StudentDriver Testing

FIG. 1 illustrates a block diagram of an exemplary driver's educationevaluation system 100 in accordance with an exemplary aspect of thepresent disclosure. Driver's education evaluation system 100 includeshardware and software applications, as well as various datacommunication channels for facilitating data communications between thevarious hardware and software components. Driver's education evaluationsystem 100 may be divided into front-end components 102 and back-endcomponents 104.

In various aspects, any suitable number of front-end components 102 maybe disposed within device 110 and/or device 111. Either of device 110and/or device 111 may be permanently or removably installed in a vehicle108 (e.g., a car, truck, etc.). Additionally or alternatively, vehicle108 may include an on-board computer 114. In various aspects, device 110and/or device 111 may be implemented as any suitable computing device,such as a smartphone, mobile device, tablet computer, laptop computer,dedicated driver's education evaluation computer, wearable computingdevice, etc. In an aspect, device 110 may be implemented as a devicethat has a smaller display than display 111. For example, device 110 maybe implemented as a smartphone and device 111 may be implemented as atablet computer. In this way, a tablet computer device 111 may functionas a “digital clipboard” and utilize a larger display screen to displayadditional information that would otherwise be impractical or difficultto view on a display of smartphone device 110.

In various aspects, device 111 may share one or more functions such thateither of device 110, device 111, and/or on-board computer 114 mayperform any portion (or all) of the functions performed by the otherdevices. As will be appreciated by those of ordinary skill in therelevant art(s), functions performed by either device 110, device 111,and/or on-board computer 114 may also be performed by device 110, device111, and/or on-board computer 114 working in concert with one another.

On-board computer 114 may be permanently installed in vehicle 108 andmay interface with various sensors in vehicle 108 (e.g., a brakingsensor, a speedometer, a tachometer, etc.) and/or may interface withvarious external output devices in vehicle 108 such as one or moretactile alert systems 120, one or more speakers 122, one or moredisplays, etc. A display is not shown in vehicle 108 in FIG. 1 forpurposes of brevity. In various aspects, on-board computer 114 may be ageneral-use on-board computer configured to perform any suitablefunctions related to vehicle operation and/or may be implemented as adedicated driver's education evaluation computer. In an aspect, on-boardcomputer 114 may be installed by the manufacturer of vehicle 108 or asan aftermarket modification to vehicle 108, for example. In variousaspects, device 110, device 111, and/or on-board computer 114 may be athin-client device which outsources any suitable portion of processingto server 140 via network 130.

On-board computer 114 may supplement any suitable number of thefunctions performed by device 110 and/or device 111 described herein by,for example, sending and/or receiving information to and from device 110and/or device 111. Device 110, device 111, and/or on-board computer 114may communicate with network 130 over links 112, 113, and 118,respectively. Additionally, device 110, device 111, and/or on-boardcomputer 114 may communicate with one another directly over links 115,116, and/or 117. Vehicle 108 may also include a tactile alert system 120(e.g., a seat that can vibrate) that may present tactile alerts to thevehicle operator 106 on command from device 110, device 111, and/oron-board computer 114. While shown in a slightly reclined sittingposition, those of ordinary skill in the art will appreciate that thestudent driver 106 could be situated in any number of ways (e.g.,reclining at a different angle, etc.) and operating the vehicle usingcontrols other than the steering wheel and pedals shown in FIG. 1 (e.g.,one or more sticks, yokes, levers, etc.).

In various aspects, front-end components 102 may include any suitablecombination of hardware and/or software components that are configuredto communicate with back-end components 104 via network 130. Network 130may be any suitable network that facilitates communications betweenfront-end components 102 and back end components 104. Network 130 mayinclude, for example, a proprietary network, a secure public internet, amobile-based network, a virtual private network or some other type ofnetwork, such as dedicated access lines, plain ordinary telephone lines,satellite links, a public switched telephone network (PSTN), etc., orany suitable combination thereof. In aspects in which network 130facilitates a connection to the Internet, data communications may takeplace over the network 130 via one or more suitable Internetcommunication protocols. Back-end components 104 may include a server140. Server 140 may include one or more computer processors configuredto execute various software applications, components of the driver'seducation evaluation system 100, and/or other suitable softwareapplications.

Server 140 may further include a database 146. Database 146 may beconfigured to store data related to the operation of driver's educationevaluation system 100. Such data might include, for example, datacollected by device 110, device 111, and/or on-board computer 114, whichmay pertain to the driver's education evaluation system 100 and may beuploaded to the server 140 in the form of images, sensor input data,data analyzed according to the methods discussed below, or any othersuitable type of data. Server 140 may access data stored in database 146when executing various functions and tasks associated with the operationof driver's education evaluation system 100.

Although driver's education evaluation system 100 is shown in FIG. 1 asincluding one server 140, one device 110, one device 111, and oneon-board computer 114, various aspects include driver's educationevaluation system 100 implementing any suitable number of servers 140,devices 110, devices 111, and/or on-board computers 114. For example,the driver's education evaluation system 100 may include a plurality ofservers 140 and a large number (e.g., 100) of devices 110, any suitablenumber of which may be interconnected via the network 130. Device 110and/or device 111 may perform the various functions described herein inconjunction with on-board computer 114 or alone (in such cases, on-boardcomputer 114 need not be present).

Furthermore, in aspects whereby more than one server 140 is implemented,processing performed by the one or more servers may be distributed amongthe plurality of servers in an arrangement known as “cloud computing.”According to this example, this configuration may provide severaladvantages, such as, for example, enabling near real-time uploads anddownloads of information as well as periodic uploads and downloads ofinformation. This may provide for a thin-client aspect of device 110,device 111, and/or on-board computer 114 discussed herein as well asacting as a backup of some or all of the data gathered by device 110,device 111, and/or on-board computer 114.

Alternatively, driver's education evaluation system 100 may include onlythe front-end components 102. For example, device 110, device 111,and/or on-board computer 114 may perform any suitable portion of theprocessing associated with gathering data, receiving user input,generating driving session and/or performance reports for the studentdriver 106, storing the driving session and/or performance reports,and/or sending the driving session and/or performance reports toback-end components 104. As such, driver's education evaluation system100 may be a “stand-alone” system, neither sending nor receivinginformation over network 130.

Server 140 may have a controller 155 that is configured to communicatewith database 146 via a link 156. As will be appreciated by those ofordinary skill in the relevant art(s), while not shown, additionaldatabases may be linked to the controller 155 in any suitable manner.Controller 155 may include a program memory 160, a processor 162, arandom-access memory (RAM) 164, and an input/output (I/O) circuit 166,any combination of which may be interconnected via an address/data bus165. In various aspects, program memory 160 may be implemented as anon-transitory tangible computer readable memory configured to storecomputer-readable instructions that when executed by the processor 162cause the server 140 to perform various acts, such as implementingvarious applications stored in program memory 160, such as a serverapplication 142 and a web server 143, for example.

The instructions for server application 142 may cause server 140 toimplement the methods described herein. While shown as a single block inFIG. 1, various aspects include server application 142 having anysuitable number of different programs, modules, routines, and/orsub-routines that may collectively cause server 140 to run serverapplication 142. Although only one microprocessor 162 is shown in FIG.1, various aspects of server 140 may include multiple microprocessors162. Similarly, aspects of the memory of controller 155 may includemultiple RAMs 164 and multiple program memories 160.

Further, while the instructions for server application 142 and webserver 143 are shown as being stored in program memory 160, variousaspects may include the instructions being additionally or alternativelystored in database 146 and/or RAM 164. Although I/O circuit 166 is shownas a single block, various aspects may include I/O circuit 166 havingany suitable number and/or types of I/O circuits. RAM(s) 164 and programmemories 160 may be implemented as semiconductor memories, magneticallyreadable memories, and/or optically readable memories, for example. Thecontroller 155 may also be configured to communicate over network 130via a link 135 and the I/O circuit 166.

In an aspect, device 110 and/or device 111 may be configured withsuitable hardware and/or software (e.g., one or more applications,programs, files, etc.) to receive data collected from on-board computer114 during a driving session via link 116. Additionally oralternatively, device 110 and/or device 111 may also be configured tocollect data via any number of respective integrated sensors, fromserver 140, and/or another suitable device not shown in FIG. 1. Invarious aspects, device 110 and/or device 111 may receive data fromon-board computer 114 via link 116, generate data via each respectivedevice's integrated data sensors, and/or share any combination of thisdata between device 110 and device 111 via link 115.

Additionally or alternatively, device 110 and/or device 111 may use anysuitable combination of data received from on-board computer 114 and/orgenerated data via each respective device's integrated data sensors togenerate one or more driving session reports, real-time status data,and/or non real-time status data, which is further discussed in detailbelow.

As used herein, data collected from any suitable device during a drivingsession from one or more of device 110, device 111, server 140, and/oron-board computer 114 and/or data generated via one or more integratedsensors of one or more of device 110, device 111 and/or on-boardcomputer 114 is collectively referred to as “status data,” or “statusmetrics.” As further discussed below, the status data may include driverstatus data, vehicle status data, as well as data from other suitablesources when applicable.

In some aspects, device 111 receives data from device 110 and/oron-board computer 114, but device 111 does not generate its own data. Inother aspects, device 111 may generate data in addition to data receivedfrom device 110 and/or on-board computer 114 or as an alternate to datathat may otherwise be received from device 110 and/or on-board computer114.

Status data received at device 111 from on-board computer 114 via link116 and/or generated via one or more integrated sensors of device 110and/or device 111 may include, for example, data corresponding to astatus of driver 106 and/or a status of vehicle 108. Examples of driverstatus data may include data related to one or more driver actions suchas driver eye movement, a direction of a driver's gaze, driver headposition, one or more driver biometrics, etc. Examples of vehicle statusdata may include data related to a steering, acceleration, braking, roadspeed, engine speed, a distance between vehicle 108 and a second vehiclein front of vehicle 108, lane position of vehicle 108, vehicle lightstatus (e.g., whether headlights are on or off), a geographic positionof vehicle 108, whether a turn signal has been activated, whetherwindshield wipers are activated, etc.

In an aspect, once the driving session has ended, device 110 and/ordevice 111 may generate a driving session report to provide feedback tothe student driver using the status data. In accordance with an aspect,device 110 and/or device 111 may be configured to generate one or moredriving session reports and/or feedback scores based on the status datausing any of the techniques as described in commonly-assigned U.S.application Ser. No. 13/844,090, which is hereby incorporated byreference in its entirety. Additionally, on-board computer 114, device110, and/or device 111 may utilize any of the techniques described inU.S. application Ser. No. 13/844,090 to process driver status and/orvehicle status data for the generation of driving session reports.

Further in accordance with such aspects, device 110 and/or device 111may be configured to generate one or more tagged driving events based onthe status data and/or data that is input by a user, such as a drivinginstructor, for example. Device 110 and/or device 111 may utilize thesetagged driving events to generate the driving session report. Examplesof aspects including the generation of tagged driving events and theirinclusion in the driving session report may be implemented using any ofthe techniques as described throughout this disclosure as well as thosedescribed in commonly-assigned co-pending U.S. application Ser. No.14/494,088, which is hereby incorporated by reference in its entirety.

In various aspects, device 111 may be configured to generate one or morestatus metrics based on the status data. In an aspect, device 111 maygenerate the status metrics as the status data is received and/orgenerated, i.e., in real-time. The status metrics may include, forexample, one or more calculated values and/or conditions interpretedfrom the status data. For example, if the status data includes thevehicle's current speed, then the corresponding generated status metricmay be a corresponding numeric value in terms of miles per hour (mph),kilometers per hour (kph), etc.

To provide another example, if the status data includes the driver'sgaze, then the corresponding status metric could include tabular datacorresponding to a gaze chart. To provide yet another example, if thestatus data included a driver's head position, then the correspondingstatus metric could include a condition associated with whether thedriver checked his blind spot or not, such as “true” or “false.” Gazetracking and a gaze chart may be determined and/or calculated byimplementing any suitable technique, such as those described incommonly-assigned co-pending U.S. application Ser. No. 14/282,437, filedon May 20, 2014, which is hereby incorporated by reference in itsentirety.

In some aspects, device 111 may be configured to format and/or displaythe generated status metrics in real-time such that the status metricsare indicative of a current status of driver 106 and/or vehicle 108. Forexample, device 111 may be configured to display the vehicle's currentspeed.

In other aspects, device 111 may be configured to format and/or displayany suitable portion of the generated status metrics as real-timemetrics and/or non real-time metrics. For example, device 111 may beconfigured to display some (or all) status metrics indicative of areal-time status of driver 106 and/or vehicle 108 while displaying otherstatus metrics (or all status metrics) that are not indicative of areal-time status of driver 106 and/or vehicle 108. For example, device111 may be configured to display non-real time status metrics such asaveraged and/or aggregated status metrics at the end of a drivingsession, for example.

Device 111 may also be configured to display both real-time metrics andnon real-time metrics at the same time. For example, device 111 maydisplay a real-time status metric indicative of the current speed ofvehicle 108 while also displaying a non real-time driver feedback scoreretrieved from a student's previous driving session. The driver feedbackscore may be calculated and/or retrieved, for example, according to anysuitable techniques as described in U.S. application Ser. No.13/844,090. In this way, driver's education evaluation system 100provides feedback regarding a current and/or previous status of a driverand/or vehicle during and after a driving session.

II. Operation of Device 110, Device 111, and/or on-Board Computer 114

FIG. 2 illustrates a detailed block diagram of a portion of exemplarydriver's education evaluation system 100 in accordance with an exemplaryaspect of the present disclosure. Device 110 and/or on-board computer114 may share several of the same components as device 111 to facilitatesimilar functions, as shown in FIG. 2. As a result, the individualcomponents of device 110 and on-board computer 114 are not shown in FIG.2 for purposes of brevity, and only differences between device 110,device 111, and on-board computer 114 will be further discussed herein.

Device 111 may include a display 202, a Global Positioning System (GPS)unit 206, a communication unit 220, a front image capture device 218, aback image capture device 222, an accelerometer array 224, a user-inputdevice 248, a speaker 246, and a controller 204.

Controller 204 includes a program memory 208, one or more of amicrocontroller or a microprocessor (MP) 210, a random-access memory(RAM) 212, and an input/output (I/O) circuit 216, each of which isinterconnected via an address/data bus 214. In various aspects, programmemory 208 may be implemented as a non-transitory tangible computerreadable media configured to store computer-readable instructions thatwhen executed by controller 204 cause controller 204 to perform variousacts. In various aspects, program memory 208 may include variousportions that may include instructions associated with correspondingfunctions to be performed by controller 204. For example, as shown inFIG. 2, program memory 208 may include an operating system 226, aplurality of software applications 230, and/or a plurality of softwareroutines 234. To provide another example, program memory 208 may includeother portions to store data that may be read from and written to byprocessor 210, such as data storage 228, for example.

In an aspect, operating system 226 may be implemented as any suitableoperating system platform depending on the particular implementation ofdevice 110, device 111, and/or on-board computer 114. For example,operating system 226 may be implemented as one of a plurality of mobileplatforms such as the iOS®, Android™, Palm® webOS, Windows®Mobile/Phone, BlackBerry® OS, or Symbian® OS mobile technologyplatforms, developed by Apple Inc., Google Inc., Palm Inc. (nowHewlett-Packard Company), Microsoft Corporation, Research in Motion(RIM), and Nokia, respectively.

In an aspect, data storage 228 may include data such as user profilesand preferences, application data for the plurality of applications 230,routine data for the plurality of routines 234, any suitable datanecessary to interact with the server 140 via network 130, and anysuitable data necessary to interact with the device 110 and/or onboardcomputer 114. In some aspects, controller 204 may also be configured tocommunicate with additional data storage mechanisms (e.g., one or morehard disk drives, optical storage drives, solid state storage devices,etc.) that reside within device 111.

In an aspect, GPS unit 206 may use “Assisted GPS” (A-GPS), satelliteGPS, or any other suitable global positioning protocol (e.g., theGLONASS system operated by the Russian government) or system thatlocates the position device 111. For example, A-GPS may utilize cellphone towers or Wi-Fi hotspots (e.g., wireless router points) viacommunications sent and/or received via communication unit 220 to moreaccurately and more quickly determine location of device 111. On theother hand, satellite GPS is typically more useful in more remoteregions that lack cell towers or Wi-Fi hotspots.

In an aspect, front and back image capture devices 218 and 222 may beintegrated as part of device 110 and/or device 111 and may beimplemented as peripheral cameras, such as webcams, cameras installedinside the vehicle 108, cameras installed outside the vehicle 108, etc.,that are configured to communicate with suitable portions of device 110and/or device 111.

In an aspect, front image capture device 218 and/or back image capturedevice 222 may be integrated as part of device 110. In accordance withsuch embodiments, status data may be sent to device 111 from device 110using information derived from front image capture device 218 and/orback image capture device 222. For example, device 110 may include frontimage capture device 218 oriented toward student driver 106 to observestudent driver 106 as part of one or more autonomous data collectionprocesses, such as eye tracking, for example. To provide anotherexample, device 110 may include back image capture device 222 orientedtoward the front of vehicle 108 to observe the road, lane markings,and/or other objects in front of vehicle 108 as part of one or moreautonomous data collection processes, such as determining a followingdistance, for example.

In some aspects, data may be collected from both front image capturedevice 218 and back image capture device 222 simultaneously. In otheraspects, data may be collected from front image capture device 218 andback image capture device 222 at separate time intervals, such as inaccordance with a time-division multiplexing schedule, for example.

In some aspects, device 110 and/or device 111 may include both a frontimage capture device 218 and a back image capture device 222. In otheraspects, device 110 and/or device 111 may include only front imagecapture device 218 or back image capture device 222. Front image capturedevice 218 and/or back image capture device 222 may include an infraredilluminator 218 i, 222 i, respectively, to facilitate low light and/ornight image capturing. Infrared illuminator 218 i, 222 i may beactivated when light is insufficient for image capturing.

In an aspect, accelerometer array 224 may be implemented as one or moreaccelerometers positioned to determine the force and direction ofmovements of device 110 and/or device 111. In some aspects,accelerometer array 224 may include an X-axis accelerometer 224 x, aY-axis accelerometer 224 y, and a Z-axis accelerometer 224 z configuredto measure the force and direction of movement in each dimension,respectively. As will be appreciated by those of ordinary skill in therelevant art(s), a three dimensional vector describing movement ofdevice 110 and/or device 111 through three dimensional space can beestablished by combining the outputs of the X-axis, Y-axis, and Z-axisaccelerometers 224 x, y, and z using any suitable methods.

GPS unit 206, front image capture device 218, back image capture device222, and accelerometer array 224 may be referred to collectively as the“sensors” of device 110 and/or device 111. As will be appreciated bythose of ordinary skill in the relevant art(s), various aspects ofdevice 110 and/or device 111 include any suitable number of additionalGPS units 206, front image capture devices 218, back image capturedevices 222, and/or accelerometer arrays 224.

Communication unit 220 may communicate with server 140 using anysuitable communication protocol over network 130 via link 113.Additionally or alternatively, communication unit 220 may communicatewith device 110 and/or on-board computer 114 using any suitablecommunication protocol via links 115 and 117, respectively. Examples ofcommunications protocols include wireless telephony network (e.g., GSM,CDMA, LTE, etc.) protocols, Wi-Fi network (802.11 standards) protocols,WiMAX network protocols, BLUETOOTH network protocols, etc. Communicationunit 220 may also be capable of communicating using a near fieldcommunication standard (e.g., ISO/IEC 18092, standards provided by theNFC Forum, etc.). Further, communication unit 220 may use one or morewired connections to facilitate communications with server 140, device110, and/or on-board computer 114.

In various aspects, user-input device 248 may be implemented as anysuitable device configured to collect user input, such as a “soft”keyboard that is displayed on the display 202 of device 110 and/oron-board computer 114, an external hardware keyboard communicating via awired or a wireless connection (e.g., a Bluetooth keyboard), an externalmouse, etc. User-input device 248 may also include a microphoneconfigured to receive user voice input. As previously discussed withreference to controllers 155 and 224, as will be appreciated by those ofordinary skill in the relevant art(s), although FIG. 2 depicts only oneprocessor 210, controller 204 may include any suitable number of MPs210.

Memory of controller 204 may include any suitable number of RAMs 212 andany suitable number of program memories 208. Although FIG. 2 depicts I/Ocircuit 216 as a single block, various aspects of I/O circuit 216 mayinclude any suitable number of different types of I/O circuits. Invarious aspects, controller 204 may implement RAM(s) 212 and programmemories 208 as any suitable type of memory, such as non-transitorycomputer readable memories, semiconductor memories, magneticallyreadable memories, and/or optically readable memories, for example.

In various aspects, one or more processors 210 may be configured toexecute any of one or more of the plurality of software applications 230and/or any one or more of the plurality of software routines 234residing in program memory 208 in addition to other softwareapplications.

In an aspect, one of the plurality of applications 230 may be a clientapplication 232 that may be implemented as a series of machine-readableinstructions for performing the various tasks associated withimplementing the driver's education evaluation system 100 as well asreceiving information, displaying information, and/or transmittinginformation between device 110, device 111, on-board computer 114,and/or server 140.

In various aspects, any of the plurality of applications 230 may beimplemented as a stand-alone system or as a system wherein the front-endcomponents 102 communicate with back-end components 104 as describedherein. Additionally, any of the plurality of applications 230 mayinclude machine-readable instruction for implementing a user interfaceto allow a user to input commands to and receive information fromdriver's education evaluation system 100 in accordance with thefunctionality supported by each respective application.

One of the plurality of applications 230 may be a native web browser236, such as Apple's Safari®, Google Android™ mobile web browser,Microsoft Internet Explorer® for Mobile, Opera Mobile™, that may beimplemented as a series of machine-readable instructions for receiving,interpreting, and displaying web page information from the server 140 orother back-end components 104 while also receiving inputs from the user.Another one of the plurality of applications 230 may include an embeddedweb browser 242 that may be implemented as a series of machine-readableinstructions for receiving, interpreting, and displaying web pageinformation from the servers 140 or other back-end components 104 withinclient application 232.

Additionally, server 140 may include any suitable number of softwareapplications. In various aspects, server 140 may include softwareapplications configured to facilitate the generation of data content tobe included in the web pages sent from the web server 143 to the device110, device 111, and/or on-board computer 114. The software applicationsmay be executed on the same computer processor as web server application143, or on different computer processors.

In aspects in which device 110, device 111, and/or on-board computer 114is a thin-client device, server 140 may perform any suitable portion ofthe processing functions remotely that would otherwise be performed bydevice 110, device 111, and/or on-board computer 114. In such aspects,device 110, device 111, and/or on-board computer 114 may gather datafrom its respective sensors as described herein, but device 110, device111, and/or on-board computer 114 may send the data to server 140 forremote processing instead of analyzing the data locally. In suchaspects, server 140 may perform the analysis of the gathered data, whichmay include any combination of status data and/or driving eventscollected via sensors and/or input by a user to generate a feedbackscore, status metrics, a driving session report, etc.

As previously discussed, various aspects of driver's educationevaluation system 100 may be performed by any combination of device 110,device 111, on-board computer 114, and/or server 140. In aspects inwhich device 110, device 111, and/or on-board computer 114 offloadprocessing tasks to server 140, native web browser 236 and/or embeddedweb browser 242 may facilitate the transfer of data using one or moreweb-based applications.

One of the plurality of routines 234 may include an image captureroutine 238 that coordinates with the image capture devices 218, 222 toretrieve image data for use with one or more of the plurality ofapplications, such as the client application 232, or for use with anyother suitable routines. Another routine in the plurality of routinesmay include an accelerometer routine 240 that determines the force anddirection of movements of device 110 and/or device 111. Theaccelerometer routine 240 may process data from the accelerometer array224 to determine a vector describing the motion of device 110 and/ordevice 111 for use with the client application 232. In some aspectswhere the accelerometer array 224 has X-axis, Y-axis, and Z-axisaccelerometers 224 x, y, z, the accelerometer routine 240 may combinethe data from each accelerometer 224 x, y, and z to establish a vectordescribing the motion of device 110 and/or device 111 through threedimensional space. Furthermore, in some aspects, the accelerometerroutine 240 may use data pertaining to less than three axes, such aswhen determining when vehicle 108 is braking.

One of the plurality of applications 230 may include a feedbackapplication 237. In an aspect, feedback application 237 may be anapplication that is installed on device 111. For example, feedbackapplication 237 may be downloaded and installed to device 111 by a user.In an aspect, feedback application 237 may include instructions forimplementing a user interface to allow a user to input commands and/orrespond to prompts. For example, feedback application 237 may allow auser to select one or more options associated with displaying statusmetrics, feedback scores, saving driving session reports, saving statusmetrics, generating driving session reports, etc.

Additionally or alternatively, feedback application 237 may includeinstructions for receiving data input from a user (e.g., via input 248),sending data to and receiving data from server 140 (e.g., via I/O 216),sending data to and receiving data from device 110, and/or on-boardcomputer 114 (e.g., via communication unit 220), and/or generating dataassociated with one or more sensors integrated within device 111 (e.g.,GPS unit 206, accelerometer array 224, etc.). For example, feedbackapplication 237 may receive data from GPS unit 206 to determine ageographic location of vehicle 108 throughout the driving session, anduse this data to facilitate displaying the position of vehicle 108 on amap in real-time.

In an aspect, one of the plurality of routines 234 may include afeedback generation and display routine 239. As used herein, “feedbackdata” may include any portion of data received, processed, generated,calculated, displayed, etc., on a display of a respective device duringa driving session. For example, feedback generation and display routine239 may process data collected via any suitable number of the pluralityof applications 230 and/or the plurality of routines 234 to generatefeedback data such as one or more status metrics, a feedback score,driving session reports, etc.

As will be appreciated by those of ordinary skill in the relevantart(s), any suitable routine may be implemented by feedback generationand display routine 239 to generate and display the feedback data. Invarious aspects, feedback generation and display routine 239 may processdata received and/or generated via feedback application 237 to generatethe feedback data and/or format the feedback data for display on display202. The feedback data may be displayed via display 202, sent to server140 via network 130, and/or sent to another suitable device viacommunication unit 220, such as device 110, for example.

Feedback generation and display routine 239 and/or feedback application237 may facilitate any suitable portion of the feedback data being sentto another device and/or stored on another device in any suitable formatthat may be accessed and viewed by a user. For example, the feedbackdata may be saved to device 111, emailed to device 110 or anotherdevice, stored on server 140 or another online storage medium, etc.

In an aspect, feedback generation and display routine 239 may processdata received and/or generated by feedback application 237 to determinea current time and/or a time associated with various portions of datareceived and/or generated by feedback application 237. For example,feedback generation and display routine 239 may derive a network timefrom data received from server 140. To provide another example, feedbackgeneration and display routine 239 may determine a time associated withstatus data received and/or generated by feedback application 237 thatmay correspond to a driving event, such as a time corresponding to alane change, a braking event, etc. In some aspects, feedback generationand display routine 239 may determine a current time from a time that isassociated with the respective received or generated data through theuse of a real-time clock, which may be integrated as part of controller204, for example. A real-time clock is not shown in FIG. 2 for purposesof brevity.

In other aspects, feedback generation and display routine 239 maydetermine a time associated with status data received by feedbackapplication 237 if the received status data includes a timestamp orother suitable time identifier from which to derive the time of theevent. For example, as will be appreciated by those of ordinary skill inthe relevant art(s), on-board computer 114 may be configured totimestamp status data as it is processed, and to send this data todevice 111 with the timestamp information. Once the time is determinedby feedback generation and display routine 239, device 111 may keeptrack of not only generated and/or status data received from device 110and/or on-board computer 114, but when the received status data wasinitially generated.

Feedback generation and display routine 239 may utilize the timeassociated with various types of status data to generate updated statusmetrics, an updated driver feedback score, an updated time until thedriving session will end, etc. For example, feedback generation anddisplay routine 239 may calculate a moving average of a driver feedbackscore throughout a driving session over a period of time using atimestamp associated with each driving event, for example.

In various aspects, the driving session report may include varyingdetails of the feedback data to provide the driver with feedbackregarding her driving performance skills. For example, the drivingsession report may include a driver feedback score, any driving eventsthat were recorded by respective sensors, input entered by aninstructor, a mapped route of the driving session, one or more taggeddriving events (as further discussed below), one or more status metricscollected during the driving session, etc.

Additionally or alternatively, any suitable number of tagged drivingevents may be generated by feedback generation and display routine 239using the data received and/or generated via feedback application 237.In accordance with such an example, the driving session report could begenerated using any suitable techniques as described in the commonlyassigned U.S. application Ser. No. 13/844,090.

Feedback data displayed to a user may include both positive and negativetypes of information. For example, an instructor could enter informationthat a turn was particularly well executed, that a student performed aslow and steady stop without excessive jerking, etc. Although mostdriving tests do not utilize positive types of driving event feedbackfor scoring purposes, this type of information is still valuable tostudent drivers who are still learning their strengths and weaknessesthroughout the evaluation process.

Although FIG. 2 shows details of device 111 and describes functions ofdata collection in terms of various elements of device 111, variousaspects include device 110 and/or onboard computer 114 collecting statusdata and sending any suitable type and amount of data to device 111.Further in accordance with such aspects, device 111 may receive statusdata and any other suitable data from device 110, server 140, and/oron-board computer 114 without device 111 generating any status data. Insuch a case, device 111 may generate one or more status metrics, driverfeedback scores, etc., based on status data and/or other suitable datareceived from one or more of device 110, server 140, and/or on-boardcomputer 114. As will be appreciated by those of ordinary skill in therelevant art(s), device 111 may be implemented having less elements thanshown in FIG. 2 to accomplish such functions.

III. Example Process of Saving and Recalling Driver Profiles

In various aspects, feedback application 237 may be configured tofacilitate the creation of driver profiles. Once created and saved aftera driving session has been completed, driver profiles may include anaggregation of driving data such as previous feedback scores, a historyof status data collected during previous driving sessions, previousdriving session reports, etc.

In accordance with various aspects, a user may utilize a suitabledevice, such as device 111, for example, as shown FIG. 1, to enterdetails about one or more drivers to create a driver profile. In anaspect, a user may utilize user-input device 248 to enter thisinformation. The details entered to create the driver profile mayinclude, for example, the driver's name, contact information, emailaddress, guardian contact information, etc. In various aspects, a usermay specify additional information to be associated with the driverprofile such as a driving group, for example. The designation of adriving group may be particularly useful when the driver profile is forone student from among several students that are taught as part of aclass or a group of classes, for example.

In various aspects, a user may choose to store one or more driverprofiles locally to the device used to create the driver profile or toanother device. For example, if an instructor created one or more driverprofiles on device 111, then the instructor could choose to save thedriver profiles on device 111, device 110, or database 146.

In various aspects, prior to starting a driving session, a user mayselect the appropriate driver profile using device 111. For example, adriver profile corresponding to “John Smith” may be stored in a suitableportion of memory associated with device 111, such as data storage 228,for example, and be retrieved by controller 204 upon selection of therespective driver profile by a user prior to the start of a new drivingsession. To provide another example, device 111 may download the driverprofile corresponding to “John Smith” from server 140 using a suitablecommunications link, such as links 113 and/or 115, for example, uponselection of the respective driver profile by a user prior to the startof a new driving session.

In various aspects, application 237 may facilitate the selection of adriver profile by a user that is organized in a suitable way, such asalphabetically, for example. To provide another example, application 237may facilitate a user locating the driver profile from several driverprofiles having the same corresponding group designation.

As will be appreciated by those of ordinary skill in the relevantart(s), various aspects include the creation, storage, identification,and retrieval of driver profiles using any suitable method, such as anysuitable techniques as described in commonly-assigned co-pending U.S.patent application Ser. No. 14/699,758, which is hereby incorporated byreference in its entirety.

IV. Example Screenshot of a Current Driving Session Feedback DataDisplay

FIG. 3 illustrates an example screenshot 300 of a device used to displaycurrent driving feedback data during a driving session in accordancewith an exemplary aspect of the present disclosure. Feedback data mayinclude, for example, the data shown in any of the portions ofscreenshot 300, which is further discussed below.

Screenshot 300 may include portions 302, 304, 306, and 308. In thepresent aspects, the following screenshot shown in FIG. 3 is an exampleof what may be displayed to a user as part of a driver feedbackapplication. In the present aspects, screenshot 300 may be displayedusing any suitable interface device, such as display 202, for example,as shown in FIG. 2. As will be appreciated by those of ordinary skill inthe relevant art(s), the example screenshot 300 shown in FIG. 3 is forillustrative purposes, and any suitable relevant data as discussedthroughout this disclosure, such as status metrics, for example, may bedisplayed to a user using any suitable format and/or design withoutdeparting from the spirit and scope of the present disclosure.

Portion 302 may include any suitable graphic, information, label, etc.,to indicate a status of the driving session, which may be a label suchas “current trip” as shown in FIG. 3, or a custom name entered by a userprior to the driving session. For example, a user may choose to name thedriving session any suitable name to later correlate the driving sessionreport with the appropriate student, group, instructor, etc. In someaspects, portion 302 may be implemented as an interactive portion of arespective display. For example, an instructor may select the “end”label of portion 302 to end a current driving session and store thedetails of the driving session as part of the corresponding driverprofile for the driver John Smith, which will be further discussed indetail below.

Portion 304 may include any suitable graphic, information, label, etc.,to indicate a driver's name and/or group, which may be the currentdriver of the vehicle, for example. In an aspect, the driver's nameand/or associated designation (e.g., “Monday Group”) displayed inportion 304 may be part of a driver profile that is selected by a userfrom a set of driver profiles before the driving session is started, aspreviously discussed.

Portion 304 may include any suitable graphic, information, label, etc.,to indicate an eye tracking gaze chart. As previously discussed, anysuitable methods may be utilized to calculate the driver's gaze, ordirection of eye movement, during the driving session. In an aspect,this gaze chart may be displayed in portion 304 in real-time. In thisway, aspects of feedback application 237 provide a driving instructor away to view details of a student driver and to monitor the student's eyemovement in real time during a driving session.

Portion 306 may include any suitable graphic, information, label, etc.,to indicate any suitable number of status metrics based on status datacorresponding to a status of driver 106, and/or a status of vehicle 108.As previously discussed with reference to FIGS. 1 and 2, aspects includethe status metrics being obtained from the status data in conjunctionwith any suitable number of relevant sensors.

As shown in FIG. 3, portion 306 includes status metrics such as thecurrent driving session trip time, the current driving session mileageaccrued since the start of the driving session, and the current vehiclespeed. Although only three status metrics are shown in portion 306,portion 306 (or another suitable portion of screenshot 300) may includeany suitable number of suitable graphics, information, labels, etc.,indicative of any suitable number of status metrics. For example, inaddition to the status metrics shown in FIG. 3, screenshot 300 maydisplay information representative of a following distance between thevehicle and another vehicle in front of the vehicle (“time tocollision,” or “TTC”), a lane position of the vehicle, a braking status(e.g., “braking”), a driver biometric status indication (e.g.,“anxious”), current weather conditions, etc.

Portion 308 may include any suitable graphic, information, label, etc.,to indicate one or more tagged driving events superimposed over a map ofa route corresponding to a current driving session. Although not shownin FIG. 3, the map displayed in portion 308 may include an indication ofthe start of the route, the end of the route, and/or a current positionand/or direction of the vehicle. In various aspects, tagged drivingevents may be generated based on a comparison between one or more statusmetrics and one or more predetermined threshold values and/or conditionsbeing met or not being met. These tagged driving events may correspondto various safety and/or driving performance considerations, such asacceleration, braking, and cornering, for example. As shown in portion308, acceleration, braking, and cornering tagged driving eventscorrespond to the labels “A,” “B,” and “C,” respectively. Since thelocation of the vehicle is monitored concurrently with the status metricdata, each of the tagged driving events may be placed on the map at therespective location where each event occurred.

Although only acceleration, cornering, and braking driving events areshown in portion 308, various embodiments include any suitable number oftagged driving events being generated and/or displayed on the map inportion 308. For example, if the current status metrics indicate thatthe current vehicle speed is 31 mph and the posted speed limit is 20mph, then portion 308 may indicate this as a tagged driving event withan appropriate label, such as “S,” for example. In various aspects, thetagged driving events may be generated when a current relevant statusmetric is greater than or less than a predetermined threshold value.Using the acceleration of the vehicle as an example, a tagged drivingevent may be generated when the measured acceleration determined fromthe respective status metrics exceeds 1.5 m/s². To provide anotherexample, a tagged driving event may be created when the vehicle speed isequal to or greater than 5 mph over the posted speed limit.

In various aspects, a scale may be used to compare the status metricsfor each respective driving event to a range of thresholds, and to labelthe status metrics with a severity level accordingly. For example, asshown in FIG. 3, portion 308 may include a color-coded or other suitabletype of labeling system to indicate more excessive acceleration,cornering, braking, etc. As will be appreciated by those of ordinaryskill in the relevant art(s), these severity scales may be based on anysuitable range of threshold values for each type of tagged drivingevent. Using acceleration as an example, a base threshold may be set as1.4 m/s². Once a driver accelerates beyond this threshold, a “light”severity tagged driving event may be generated and placed on the map inportion 308. A moderate acceleration tagged driving event couldcorrespond to acceleration values less than 2.4 m/s² but greater than2.0 m/s², for example, while severe acceleration tagged driving eventscould correspond to those exceeding 2.4 m/s², for example. As will beappreciated by those of ordinary skill in the relevant art(s), statusmetric data may be measured in accordance with any suitable relevantsensor to calculate the desired corresponding status metric.

In various aspects, the thresholds, or threshold ranges, used todetermine the severity of tagged driving events may be determined basedon a number of conditions. For example, thresholds (or threshold ranges)may change dynamically based on changes in the status metrics. Forexample, a tagged driving event may be generated when a driver isfollowing another vehicle closer than a threshold distance, but anacceptable threshold distance may be dependent on the vehicle's speedand/or other factors, such as the weather conditions. Aspects includetagged driving event thresholds being adjusted from an initial thresholdvalue, such as distance between cars, for example, based on thesefactors.

To provide another example, threshold ranges may be associated with atype of vehicle, which could be part of the driver's profile. Forexample, if a driver has an assigned car, then these threshold rangesmay be used to generate tagged driving events using vehicle-specificthresholds based on the type of car used by the driver. For example, asport utility vehicle (SUV) may be assigned lower tagged driving eventseverity thresholds for cornering events than a those for a sedan.

In various aspects, threshold ranges or other conditions triggering thegeneration of a tagged driving event may be based on any suitableportion of the supplemental data. For example, as will be appreciated bythose of ordinary skill in the relevant art(s), a TTC value may bedetermined from a calculated time-to-stop based on a current vehiclespeed and distance between vehicles. Therefore, a threshold TTC may bedecreased if the supplemental data includes weather informationindicating that it is raining.

To provide another example, a threshold speed limit may be reduced from5 miles over the posted limit to 5 miles under the posted limit in rainyconditions. To provide yet another example, a tagged driving event maybe generated only when the supplemental data warrants such a condition.To illustrate this example, if the vehicle lights are off when it israining during the daytime an tagged driving event may be generated ifthis is a requirement in accordance with state and/or local laws, eventhough a tagged driving event would not otherwise be generated duringthe daytime. In this way, a relevant application and/or routine, such asfeedback application 237 and/or feedback generation and display routine239, for example, may dynamically interpret new status data and/orsupplemental data to continuously adjust the appropriate thresholdsassociated with the generation of tagged driving events in real-time.

In various aspects, data that is compared to the status metrics togenerate the tagged driving events may be received, calculated, and/orgenerated from another suitable device. For example, as will beappreciated by those of ordinary skill in the relevant art(s), GPS datamay be referenced to determine the posted speed limit corresponding tothe vehicle's current location. Application 237 and/or display routine239 may use this posted speed limit data to generate tagged drivingevents based on a comparison between the vehicle's current speed and theposted speed limit data derived from the status and/or supplementaldata.

Additionally or alternatively, portion 308 may include an interactiveportion, such as the “SET PIN” portion shown in FIG. 3, for example. Inaccordance with such aspects, a user may use this interactive portion tomanually generate any suitable number of custom tagged driving events.For example, two custom tagged driving events are shown in FIG. 3 aspart of portion 308, which are indicated by the “pin note” legend iconshown in portion 308. These custom tagged driving events may be enteredby an instructor as they are observed, thus placing each custom taggeddriving event on the map within portion 308 at the location of thevehicle where each event occurred. In addition to the entry of thecustom tagged driving event on the map, a user may also enter a noteand/or description associated with the driving event. For example, adriving instructor could enter a description such as “no complete stopat intersection of Elm and Main,” “driver did not come to a completestop,” etc. Custom tagged driving events may be particularly useful whena driving instructor observes an event that is important to access astudent's driving skills but may not be indicated (or easily determinedfrom) the status metrics.

In various aspects, a pull down menu may be utilized by a user to entertext for a corresponding driving event. In various aspects, a noteentered by a user may be stored and later accessed via a pull-down menu,as shown by the symbol next to the text entry in FIG. 3. In this way,commonly used notes may be quickly accessed and reused for subsequentdriving events throughout a driving session. In some aspects, commontext entries may be stored in the pull down menu for quick accessthroughout the driving session. These “quick” entries may be preloadedwith feedback application 237, for example.

In addition, various aspects include portion 308 displaying any suitablenumber of tagged driving events, such as those described incommonly-assigned co-pending U.S. application Ser. No. 14/494,088, aspreviously discussed.

In some aspects, once the driving session has ended, a user may select“end” from within portion 302 to indicate the end of the drivingsession. For example, a user may tap his finger on this part of portion302 with his finger. Upon the user selecting the “end” function, anysuitable portion of the feedback data may be sent to another device,saved locally or stored to another device. As previously discussed withrespect to FIG. 1, for example, the portion indicating “end” may allow auser to generate and/or to save driving session reports and/or anyfeedback data such as the status metrics, tagged driving eventsgenerated during the driving session, the mapped route of the drivingsession, etc., to a device, which may be the same device or a differentdevice as the device in which screenshot 300 is displayed.

The user may choose to end the driving session at the actual end of thedriving session or prematurely. If the user ends the driving sessionprematurely, any feedback data saved or shared, and/or any drivingsession report generated after the driving session has prematurely endedmay be based on the feedback data collected up to the point when thedriving session was ended.

In other aspects, the end of the driving session may be determinedwithout user intervention. This determination could be made, forexample, based on a comparison of an elapsed time and/or a position ofthe vehicle within a predetermined driving session route, for example.In accordance with such aspects, this determination may be made throughutilization of the appropriate status metrics, such as GPS data, forexample.

In aspects whereby the end of the driving session is determined withoutuser intervention, one or more actions may be executed upon such adetermination. For example, if GPS data indicates that the drivingsession has ended, a driving session report may be automaticallygenerated and sent to another device. To provide another example, if theGPS data indicates that the driving session has ended, the feedback datacollected during the driving session may be automatically saved to asuitable device, emailed to a user, etc.

V. Example Screenshot of a Driving Session Report Display

FIG. 4A illustrates an example screenshot 400 of a device used todisplay a driving session report after a driving session has beencompleted in accordance with an exemplary aspect of the presentdisclosure. In the present aspects, screenshot 400 is an example of whatmay be displayed to a user as part of a driving session report. In anaspect, screenshot 400 may be displayed to a user upon a user selecting,or feedback application 237 detecting, the end of a driving session, aspreviously discussed with reference to FIG. 3.

In the present aspects, screenshot 400 may be displayed using anysuitable interface device, such as display 202, for example, as shown inFIG. 2. As will be appreciated by those of ordinary skill in therelevant art(s), the example screenshot 400 shown in FIG. 4 is forillustrative purposes, and any suitable data as described herein may beincluded as part of the driving session report and be displayed to auser using any suitable format and/or design without departing from thespirit and scope of the present disclosure.

Portion 402 may include any suitable graphic, information, label, etc.,to indicate that the user is viewing the driving session report, whichmay be a label such as “trip summary,” for example, as shown in FIG. 4.

Portion 404 may include any suitable graphic, information, label, etc.,to indicate the driver's name, any suitable feedback data measured for aselected driving session, such as status metrics, for example, and/or afeedback score, rating, or other suitable assessment indicative of thedriver's skills based on a selected driving session. Using the exampleof the driving session discussed with reference to FIG. 3, screenshot400 may be an example of a driving session report that is displayed oncethe driver has completed the driving session route as shown in portion308 of FIG. 3, as previously discussed. To provide another example, thedriving session report shown in FIG. 4A may be loaded onto a suitabledevice upon selection of a corresponding driver profile, for example, inthis case a driver profile of John Smith.

As shown in FIG. 4A, portion 404 may include the driver's currentfeedback score calculated from feedback data measured during acorresponding driving session, which may be represented graphicallyand/or numerically. The example shown in FIG. 4A includes both a numeric(“79”) and graphical (circular icon) representation of the driverfeedback score. In the example shown in FIG. 4A, the driver's feedbackscore is evaluated using an average of three status metric valuescorresponding to acceleration, braking, and cornering. Although astraight average formula is used to determine a driver feedback score of79 in FIG. 4A, aspects include using a weighted average to assigngreater weights to some status metrics over others, such as weightingacceleration twice as heavily as braking and cornering, etc. Althoughonly three status metric values are shown in FIG. 4A, aspects includeany suitable number of status metrics being displayed as part of thedriving session report. Aspects include the driver feedback score beingbased on any suitable combination of status metrics, whether or notthese status metrics are displayed in screenshot 400.

In various aspects, the status metric values may be calculated using anysuitable numeric system. For example, each student may start out with aperfect score of 100 for each status metric, with each driving eventcorresponding to each metric further reducing this score by an amountbased on the severity of the driving event, the severity beingdetermined as previously discussed with reference to FIG. 3. The driverfeedback score may be calculated using any suitable technique, such asany of the techniques as described in commonly-assigned co-pending U.S.application Ser. No. 13/844,090, for example.

VI. An Example Feedback Display Method

FIG. 5 illustrates an example feedback display method 500 in accordancewith an exemplary aspect of the present disclosure. In the presentaspect, method 500 may be implemented by any suitable device, such asdevice 110, device 111, on-board computer 114, and/or server 140, asshown in FIG. 2, for example. In an aspect, method 500 may be performedby one or more processors, applications, and/or routines, such as anysuitable portion of controller 204, applications 230, and/or routines234, for example, as shown in FIG. 2.

Method 500 starts when a first device receives status data from a seconddevice (block 502). The first and second devices could include, forexample, device 110 and device 111, respectively. This status data couldinclude, for example, status data corresponding to a status of driver106 and/or a status of vehicle 108, for example, as shown and describedwith reference to FIG. 1. In an aspect, the status data may be generatedat device 110 using any relevant sensor and send to device 111 (block502). Additionally or alternatively, method 500 may include device 110,server 140, and/or on-board computer 114 generating the status data viaany relevant sensors and device 110 relaying status data to device 111,in an aspect (block 502). In an aspect, the first device may receive thestatus data using any suitable communication device, such as I/O circuit216 and/or communication unit 220, for example, as shown in FIG. 2.

Method 500 may include the first device generating and displaying one ormore real-time status metrics based on the received status data (block504). This could include, for example, the first device generating oneor more calculated values and/or conditions interpreted from the statusdata, as shown and described with reference to FIG. 1. In variousaspects, the first device may generate the real-time status metricsusing any suitable processing device, application, and/or routine, suchas controller 204, feedback application 237, and/or feedback generationand display routine 239, for example, as shown in FIG. 2. In an aspect,method 500 could include the status metrics being displayed in anysuitable portion of a suitable display, such as portion 304 and/or 306,for example, as shown in FIG. 3 (block 504).

Method 500 may include generating and displaying one or more taggeddriving events (block 506). This may include, for example, the firstdevice generating one or more tagged driving events based on one or morestatus data values exceeding one or more thresholds, as previouslydiscussed with reference to acceleration, braking, and cornering statusmetrics displayed within portion 308 of screenshot 300, as shown in FIG.3 (block 506). This may also include, for example, a driving instructormanually entering a tagged driving event and an accompanyingdescription, which is in turn displayed on the map as a custom taggeddriving event, as previously discussed with reference to the manuallyentered tagged driving event with an accompanying description of “nocomplete stop at intersection of Elm and Main”, within portion 308 ofscreenshot 300, as shown in FIG. 3 (block 506).

Once the driving session has ended, either via automatic detectionthereof of via a user selecting an appropriate option, such as “end” asdisplayed in portion 302 of screenshot 300, as shown in FIG. 3, method500 includes calculating and displaying one or more summarized drivingsession status metrics (block 508). Again, in accordance with suchaspects, the first device may determine whether the driving session hasended could be using any suitable processing device, application, and/orroutine, such as controller 204, feedback application 237, and/orfeedback generation and display routine 239, for example, as shown inFIG. 2.

The summarized driving session status metrics could include, forexample, one or more status metrics as shown in portion 406 ofscreenshots 400 and 450 of FIGS. 4A and 4B, respectively (block 508). Inaddition, the summarized driving session status metrics could include,for example, the tagged driving events as shown in portion 408 ofscreenshot 400 (block 508). To provide yet another example, thesummarized driving session status metrics could include an eye trackingreport as shown in portion 452 of screenshot 450 (block 508). In variousaspects, the first device may generate the summarized driving sessionstatus metrics using any suitable processing device, application, and/orroutine, such as controller 204, feedback application 237, and/orfeedback generation and display routine 239, for example, as shown inFIG. 2.

Method 500 may include calculating and displaying a driver feedbackscore (block 510). In various aspects, the first device may calculateand display the driver feedback score using any suitable processingdevice, application, and/or routine, such as controller 204, feedbackapplication 237, and/or feedback generation and display routine 239, forexample, as shown in FIG. 2. In an aspect, method 500 could optionallyinclude, for example, a driver feedback score being generated based onany suitable algorithm and/or routine, as previously discussed withreference to FIGS. 4A and 4B (block 510). In an aspect, method 500 couldinclude the driver feedback score being generated and displayed in anysuitable portion of a suitable display, such as portion 404, forexample, as shown in FIGS. 4A-4B (block 510).

Although the disclosure uses various examples of a student driver anddriving instructor using the disclosed feedback application, variousaspects may apply to other users as well. For example, various aspectsinclude using the feedback application in conjunction with drivers beingretested, reassessed, and/or rehabilitated, and is not limited to onlynew driving students.

The following additional considerations apply to the foregoingdiscussion. Throughout this specification, plural instances mayimplement components, operations, or structures described as a singleinstance. Although individual operations of one or more methods areillustrated and described as separate operations, one or more of theindividual operations may be performed concurrently, and nothingrequires that the operations be performed in the order illustrated.Structures and functionality presented as separate components in exampleconfigurations may be implemented as a combined structure or component.Similarly, structures and functionality presented as a single componentmay be implemented as separate components. These and other variations,modifications, additions, and improvements fall within the scope of thesubject matter of the present disclosure.

Additionally, certain aspects are described herein as including logic ora number of components or modules. Modules may constitute eithersoftware modules (e.g., code stored on a machine-readable medium) orhardware modules. A hardware module is tangible unit capable ofperforming certain operations and may be configured or arranged in acertain manner. In example aspects, one or more computer systems (e.g.,a standalone, client or server computer system) or one or more hardwaremodules of a computer system (e.g., a processor or a group ofprocessors) may be configured by software (e.g., an application orapplication portion) as a hardware module that operates to performcertain operations as described herein.

In some cases, a hardware module may include dedicated circuitry orlogic that is permanently configured (e.g., as a special-purposeprocessor, such as a field programmable gate array (FPGA) or anapplication-specific integrated circuit (ASIC)) to perform certainoperations. A hardware module may also include programmable logic orcircuitry (e.g., as encompassed within a general-purpose processor orother programmable processor) that is temporarily configured by softwareto perform certain operations. It will be appreciated that the decisionto implement a hardware module in dedicated and permanently configuredcircuitry or in temporarily configured circuitry (e.g., configured bysoftware) may be driven by cost and time considerations.

Accordingly, the term hardware should be understood to encompass atangible entity, be that an entity that is physically constructed,permanently configured (e.g., hardwired), or temporarily configured(e.g., programmed) to operate in a certain manner or to perform certainoperations described herein. Considering aspects in which hardwaremodules are temporarily configured (e.g., programmed), each of thehardware modules need not be configured or instantiated at any oneinstance in time. For example, where the hardware modules comprise ageneral-purpose processor configured using software, the general-purposeprocessor may be configured as respective different hardware modules atdifferent times. Software may accordingly configure a processor, forexample, to constitute a particular hardware module at one instance oftime and to constitute a different hardware module at a differentinstance of time.

Hardware and software modules can provide information to, and receiveinformation from, other hardware and/or software modules. Accordingly,the described hardware modules may be regarded as being communicativelycoupled. Where multiple of such hardware or software modules existcontemporaneously, communications may be achieved through signaltransmission (e.g., over appropriate circuits and buses) that connectthe hardware or software modules. In aspects in which multiple hardwaremodules or software are configured or instantiated at different times,communications between such hardware or software modules may beachieved, for example, through the storage and retrieval of informationin memory structures to which the multiple hardware or software moduleshave access. For example, one hardware or software module may perform anoperation and store the output of that operation in a memory device towhich it is communicatively coupled. A further hardware or softwaremodule may then, at a later time, access the memory device to retrieveand process the stored output. Hardware and software modules may alsoinitiate communications with input or output devices, and can operate ona resource (e.g., a collection of information).

The various operations of example methods described herein may beperformed, at least partially, by one or more processors that aretemporarily configured (e.g., by software) or permanently configured toperform the relevant operations. Whether temporarily or permanentlyconfigured, such processors may constitute processor-implemented modulesthat operate to perform one or more operations or functions. The modulesreferred to herein may, in some example aspects, compriseprocessor-implemented modules.

Similarly, the methods or routines described herein may be at leastpartially processor-implemented. For example, at least some of theoperations of a method may be performed by one or processors orprocessor-implemented hardware modules. The performance of certain ofthe operations may be distributed among the one or more processors, notonly residing within a single machine, but deployed across a number ofmachines. In some example aspects, the processor or processors may belocated in a single location (e.g., within a home environment, an officeenvironment or as a server farm), while in other aspects the processorsmay be distributed across a number of locations.

The one or more processors may also operate to support performance ofthe relevant operations in a “cloud computing” environment or as a SaaS.For example, at least some of the operations may be performed by a groupof computers (as examples of machines including processors), theseoperations being accessible via a network (e.g., the Internet) and viaone or more appropriate interfaces (e.g., application program interfaces(APIs).)

The performance of certain of the operations may be distributed amongthe one or more processors, not only residing within a single machine,but deployed across a number of machines. In some example aspects, theone or more processors or processor-implemented modules may be locatedin a single geographic location (e.g., within a home environment, anoffice environment, or a server farm). In other example aspects, the oneor more processors or processor-implemented modules may be distributedacross a number of geographic locations.

Some portions of this specification are presented in terms of algorithmsor symbolic representations of operations on data stored as bits orbinary digital signals within a machine memory (e.g., a computermemory). These algorithms or symbolic representations are examples oftechniques used by those of ordinary skill in the data processing artsto convey the substance of their work to others skilled in the art. Asused herein, an “algorithm” or a “routine” is a self-consistent sequenceof operations or similar processing leading to a desired result. In thiscontext, algorithms, routines and operations involve physicalmanipulation of physical quantities. Typically, but not necessarily,such quantities may take the form of electrical, magnetic, or opticalsignals capable of being stored, accessed, transferred, combined,compared, or otherwise manipulated by a machine. It is convenient attimes, principally for reasons of common usage, to refer to such signalsusing words such as “data,” “content,” “bits,” “values,” “elements,”“symbols,” “characters,” “terms,” “numbers,” “numerals,” or the like.These words, however, are merely convenient labels and are to beassociated with appropriate physical quantities.

Unless specifically stated otherwise, discussions herein using wordssuch as “processing,” “computing,” “calculating,” “determining,”“presenting,” “displaying,” or the like may refer to actions orprocesses of a machine (e.g., a computer) that manipulates or transformsdata represented as physical (e.g., electronic, magnetic, or optical)quantities within one or more memories (e.g., volatile memory,non-volatile memory, or a combination thereof), registers, or othermachine components that receive, store, transmit, or displayinformation.

As used herein any reference to “one aspect” or “an aspect” means that aparticular element, feature, structure, or characteristic described inconnection with the aspect is included in at least one aspect. Theappearances of the phrase “in one aspect” in various places in thespecification are not necessarily all referring to the same aspect.

Some aspects may be described using the expression “coupled” and“connected” along with their derivatives. For example, some aspects maybe described using the term “coupled” to indicate that two or moreelements are in direct physical or electrical contact. The term“coupled,” however, may also mean that two or more elements are not indirect contact with each other, but yet still co-operate or interactwith each other. The aspects are not limited in this context.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,method, article, or apparatus that comprises a list of elements is notnecessarily limited to only those elements but may include otherelements not expressly listed or inherent to such process, method,article, or apparatus. Further, unless expressly stated to the contrary,“or” refers to an inclusive or and not to an exclusive or. For example,condition A or B is satisfied by any one of the following: A is true (orpresent) and B is false (or not present), A is false (or not present)and B is true (or present), and both A and B are true (or present).

In addition, use of the “a” or “an” are employed to describe elementsand components of the aspects herein. This is done merely forconvenience and to give a general sense of the description. Thisdescription should be read to include one or at least one and thesingular also includes the plural unless it is obvious that it is meantotherwise.

Upon reading this disclosure, those of skill in the art will appreciatestill additional alternative structural and functional designs forproviding an interface for receiving data during a driving session anddisplaying feedback data through the disclosed principles herein. Thus,while particular aspects and applications have been illustrated anddescribed, it is to be understood that the disclosed aspects are notlimited to the precise construction and components disclosed herein.Various modifications, changes and variations, which will be apparent tothose skilled in the art, may be made in the arrangement, operation anddetails of the method and apparatus disclosed herein without departingfrom the spirit and scope defined in the appended claims.

What is claimed is:
 1. A computer-implemented method for displayingreal-time data during a driving session on a first mobile computingdevice located in a vehicle, comprising: receiving, at the first mobilecomputing device by one or more processors, a plurality of statusmetrics in real-time from a second mobile computing device located inthe vehicle during the driving session, the plurality of status metricsbeing generated by the second mobile computing device and including dataindicative of one or more of (i) the vehicle's acceleration, (ii) thevehicle's movement while braking, and (iii) the vehicle's movement whilecornering, wherein the second mobile computing device includes a seconddisplay configured to display driving session information based upon theplurality of status metrics, and wherein the first mobile computingdevice includes a first display configured to concurrently display alarger amount of different types of driving session information basedupon the plurality of status metrics than the different types of drivingsession information that could be concurrently displayed via the seconddisplay; generating, at the first mobile computing device by one or moreprocessors, a tagged driving event in real-time when one of theplurality of status metrics meets or exceeds a respective status metricthreshold; and concurrently displaying, on the first display, thedriving session information including (i) a map showing a route drivenby the vehicle during the driving session and the tagged driving eventon the map in real-time at a location where the tagged driving eventoccurred, (ii) a real-time driver status, and (iii) a real-time vehiclestatus.
 2. The method of claim 1, wherein the real-time driver statuscomprises one or more of: driver eye movement; a direction of a driver'sgaze; driver head position; or a driver biometric.
 3. The method ofclaim 1, wherein the real-time vehicle status comprises one or more of:vehicle road speed; vehicle engine speed; a time to collision (CTT); alane position of the vehicle; vehicle light status; or vehicle brakingstatus.
 4. The method of claim 1, wherein the tagged driving event isfrom among a plurality of tagged driving events that occur during thedriving session, and further comprising: calculating, at the firstmobile computing device by one or more processors, a severity level foreach of the plurality of tagged driving events based upon an amount bywhich each of the plurality of tagged driving events exceeds arespective status metric threshold; and calculating, at the first mobilecomputing device by one or more processors, a driver feedback scoreafter the driving session has ended based on the severity level of eachof the plurality of tagged driving events.
 5. The method of claim 1,wherein the status metric threshold corresponds to one or more of: athreshold acceleration status metric value; a threshold cornering statusmetric value; and a threshold braking status metric value.
 6. The methodof claim 1, wherein the plurality of status metrics received inreal-time from the second mobile computing device are utilized toindicate the driver status, and further comprising: receiving a secondplurality of status metrics in real-time from an on-board computerassociated with the vehicle, the second plurality of status metricsbeing utilized to indicate the vehicle status.
 7. The method of claim 1,further comprising: receiving, at the first mobile computing device byone or more processors, a user input indicative of a driving eventduring the driving session; determining, at the first mobile computingdevice by one or more processors, a location of the vehicle where thedriving event occurred at a time corresponding to when the user inputwas received; and displaying, on the first display, a custom taggeddriving event on the map at the location of the vehicle where thedriving event occurred in real-time.
 8. A non-transitory, tangiblecomputer-readable medium storing machine readable instructions fordisplaying real-time data during a driving session on a first mobilecomputing device located in a vehicle, that when executed by aprocessor, cause the processor to: receive a plurality of status metricsin real-time from a second mobile computing device located in thevehicle during the driving session, the plurality of status metricsbeing generated by the second mobile computing device and including dataindicative of one or more of (i) the vehicle's acceleration, (ii) thevehicle's movement while braking, and (iii) the vehicle's movement whilecornering, wherein the second mobile computing device includes a seconddisplay configured to display driving session information based upon theplurality of status metrics, and wherein the first mobile computingdevice includes a first display configured to concurrently display alarger amount of different types of driving session information basedupon the plurality of status metrics than the different types of drivingsession information that could be concurrently displayed via the seconddisplay; generate a tagged driving event in real-time when one of theplurality of status metrics meets or exceeds a respective status metricthreshold; and concurrently display, on the first display, the drivingsession information including (i) a map showing a route driven by thevehicle during the driving session and the tagged driving event on themap in real-time at a location where the tagged driving event occurred,(ii) a real-time driver status, and (iii) a real-time vehicle status. 9.The non-transitory, tangible computer-readable medium of claim 8,wherein the real-time driver status comprises one or more of: driver eyemovement; a direction of a driver's gaze; driver head position; or adriver biometric.
 10. The non-transitory, tangible computer-readablemedium of claim 8, wherein the real-time vehicle status comprises one ormore of: vehicle road speed; vehicle engine speed; time to collision(CTT); a lane position of the vehicle; vehicle light status; or vehiclebraking status.
 11. The non-transitory, tangible computer-readablemedium of claim 8, wherein the tagged driving event is from among aplurality of tagged driving events that occur during the drivingsession, and further including instructions, that when executed by theprocessor, cause the processor to: calculate a severity level for eachof the plurality of tagged driving events based upon an amount by whicheach of the plurality of tagged driving events exceeds a respectivestatus metric threshold; and calculate a driver feedback score after thedriving session has ended based on the severity level of each of theplurality of tagged driving events.
 12. The non-transitory, tangiblecomputer-readable medium of claim 8, wherein the status metric thresholdcorresponds to one or more of: a threshold acceleration status metricvalue; a threshold cornering status metric value; and a thresholdbraking status metric value.
 13. The non-transitory, tangiblecomputer-readable medium of claim 8, wherein the plurality of statusmetrics received in real-time from the second mobile computing deviceare utilized to indicate the driver status, and further includinginstructions, that when executed by the processor, cause the processorto receive a second plurality of status metrics in real-time from anon-board computer associated with the vehicle, the second plurality ofstatus metrics being utilized to indicate the vehicle status.
 14. Thenon-transitory, tangible computer-readable medium of claim 9, furtherincluding instructions, that when executed by the processor, cause theprocessor to: receive a user input indicative of a driving event duringthe driving session; determine a location of the vehicle where thedriving event occurred at a time corresponding to when the user inputwas received; and display, on the first display, a custom tagged drivingevent on the map at the location of the vehicle where the driving eventoccurred.
 15. A first mobile computing device for displaying real-timedata during a driving session when located in a vehicle, comprising: aprocessor configured to: receive a plurality of status metrics inreal-time from a second mobile computing device located in the vehicleduring the driving session, the plurality of status metrics beinggenerated by the second mobile computing device and including dataindicative of one or more of (i) the vehicle's acceleration, (ii) thevehicle's movement while braking, and (iii) the vehicle's movement whilecornering; and generate a tagged driving event in real-time when one ofthe plurality of status metrics meets or exceeds a respective statusmetric threshold, wherein the second mobile computing device includes asecond display configured to display driving session information basedupon the plurality of status metrics, and a first display configured toconcurrently display a larger amount of different types of drivingsession information based upon the plurality of status metrics than thedifferent types of driving session information that could beconcurrently displayed via the second display; and a graphicalprocessing unit (GPU) configured to cause the first display toconcurrently display the driving session information including (i) a mapshowing a route driven by the vehicle during the driving session and thetagged driving event on the map in real-time at a location where thetagged driving event occurred, (ii) a real-time driver status, and (iii)a real-time vehicle status.
 16. The first mobile computing device ofclaim 15, wherein the real-time driver status comprises one or more of:driver eye movement; a direction of a driver's gaze; driver headposition; or a driver biometric.
 17. The first mobile computing deviceof claim 15, wherein the real-time vehicle status comprises one or moreof: vehicle road speed; vehicle engine speed; time to collision (CTT); alane position of the vehicle; vehicle light status; or vehicle brakingstatus.
 18. The first mobile computing device of claim 15, wherein thetagged driving event is from among a plurality of tagged driving eventsthat occur during the driving session, and wherein the processor isfurther configured to: calculate a severity level for each of theplurality of tagged driving events based upon an amount by which each ofthe plurality of tagged driving events exceeds a respective statusmetric threshold; and calculate a driver feedback score after thedriving session has ended based on the severity level of each of theplurality of tagged driving events.
 19. The first mobile computingdevice of claim 15, wherein the status metric threshold corresponds toone or more of: a threshold acceleration status metric value; athreshold cornering status metric value; and a threshold braking statusmetric value.
 20. The first mobile computing device of claim 15, whereinthe plurality of status metrics received in real-time from the secondmobile computing device are utilized to indicate the driver status, andwherein the processor is further configured to receive a secondplurality of status metrics in real-time from an on-board computerassociated with the vehicle, the second plurality of status metricsbeing utilized to indicate the vehicle status.
 21. The first mobilecomputing device of claim 15, wherein the processor is furtherconfigured to: receive a user input at the first mobile computing deviceindicative of a driving event during the driving session; and determinea location of the vehicle where the driving event occurred at a timecorresponding to when the user input was received, and and wherein theGPU is further configured to display, on the first display, a customtagged driving event on the map at the location of the vehicle where thedriving event occurred.
 22. The method of claim 1, wherein: thereal-time driver status includes a gaze location chart that provides anindication of a direction of the driver's gaze in real-time during thedriving session, the real-time vehicle status includes a speed indicatorthat provides an indication of a current vehicle speed in real-timeduring the driving session, and the act of concurrently displaying thedriving session information includes concurrently displaying (i) the mapshowing a route driven by the vehicle during the driving session and thetagged driving event on the map in real-time at a location where thetagged driving event occurred, (ii) the gaze location chart, and (iii)the speed indicator.
 23. The non-transitory, tangible computer-readablemedium of claim 8, wherein: the real-time driver status includes a gazelocation chart that provides an indication of a direction of thedriver's gaze in real-time during the driving session, the real-timevehicle status includes a speed indicator that provides an indication ofa current vehicle speed in real-time during the driving session, andwherein the instructions to concurrently display the driving sessioninformation further include instructions that, when executed by theprocessor, cause the processor to concurrently display (i) the mapshowing a route driven by the vehicle during the driving session and thetagged driving event on the map in real-time at a location where thetagged driving event occurred, (ii) the gaze location chart, and (iii)the speed indicator.
 24. The first mobile computing device of claim 15,wherein: the real-time driver status includes a gaze location chart thatprovides an indication of a direction of the driver's gaze in real-timeduring the driving session, the real-time vehicle status includes aspeed indicator that provides an indication of a current vehicle speedin real-time during the driving session, and the GPU is furtherconfigured to cause the first display to concurrently display (i) themap showing a route driven by the vehicle during the driving session andthe tagged driving event on the map in real-time at a location where thetagged driving event occurred, (ii) the gaze location chart, and (iii)the speed indicator.